撰寫使用者故事 User Story

完成 Persona 後，我開始根據米米這個角色，想像她使用產品的動機與情境，並根據需求來制定產品的功能。
為了更好的理解使用者故事的用法，我上了一堂Udemy的線上課並摘要了筆記，想了解更多 User Story 的用法和細節可以參考這裡。

我是使用 Miro 作為使用者故事的白板工具，但用了一陣子後，我更推薦 Whimsical，個人更喜歡它的操作方式。

如同課程中提到的基礎概念，使用者故事可以有各式各樣的型態，但基本都遵循格式如下：

• As a： 身為一個…(使用者的身分描述)
• I want： 我想要…(描述行動或期望)
• So that： 這樣才可以…(達成某個目的)

課程的建議是，不要想太多，先把故事寫出來就對了！。
所以我根據人物誌和最開始的產品製作動機，寫了九個「米米為什麼需要吃吃記帳」的故事，包含時機、理由、背景。
這九個大故事將作為產品的Epic（大型功能故事，或是叫史詩），做為開發的基礎。

或許產品開發到後面，再回過頭來看，會發現有些故事不那麼適合，但是，使用者故事是可以更迭、增減的，所以現在看到的只是「過程」而不是「結果」。

拆分使用者故事

有了Epic後，我需要再把這些故事拆成主要的功能(Features)，再依照功能拆到可以直接開發的底層故事(stories)，放 Backlog 裡。
這裡先以第一個 Epic 舉例，選擇這個 Epic 也是因為我認為它涵蓋了幾乎全部的核心功能：

拆分故事的疑惑

在練習拆分故事的過程中，我遇到了一些疑問，並找到了答案：

1. 在描述 Feature 和 User Stories 時，需要每一張便利貼都使用「As a… I want…so that…」的格式嗎？
   我認為不需要每個故事都使用「身為…我想要…所以」的格式。完整的格式只要用於 Epic即可，對於比較小的故事，可以直接描述具體的任務和功能。
   不過，我後來在其他課程中，有看到一些團隊選擇保留完整的描述，所以這還是要依照團隊的習慣決定。

2. 拆分完第一個 Epic 後，已經有很多任務可以開始進行。那是否需要等到所有故事拆解完畢後再開始行動呢？
   AI的建議是 不必等所有故事拆完才能開始行動。一旦有 User Stories 拆解到可以放入 backlog ，就可以進行開發和測試了。它的理由是，這種方法可以讓產品快速迭代，靈活調整開發流程。
   不過，我後來覺得如果時間允許，還是建議全部拆完再開始，避免重工和故事需要合併、刪減的情況。

3. 使用者故事和設定最小可行性產品（MVP）的關係？
   課程中提到，我們可以根據使用者故事所透露的「價值」，來決定哪些是 MVP 的範圍，確保在展示 prototype 時，能夠包含所有核心價值。所以圖中我有標註紅色的「第一階段」的記號。
   只是我後來理解到，MVP 的設定不僅僅參考使用者故事，還有其他因素需要考量，因此會在後面另立一篇討論。

撰寫使用者故事的心得

有了使用者故事的輔助，我對實際需要什麼樣的功能更有信心，並大致理解了產品的範圍。會有這樣的心情，是因為一開始我光有想法時，就把一堆東西塞進 Jira 裡，但填越困惑，不確定自己是否考量了全部的需求？還有這一長串任務，該從哪個開始製作？
等使用者故事梳理完後，我更新了 Jira，終於清楚了整體的架構，看起來清爽很多！

另外，我強烈推薦在撰寫使用者故事的過程，善用 AI 的文字完善功能。有些時候想法很多，要濃縮在一張便利貼上是蠻困難的，而擅長文字的 AI 往往能提供多個可能的選項，精準地抓住我想傳達的意思，非常有幫助！

接下來，我要分析顧客旅程地圖 Customer Journey Map，確定營養師服務和吃吃記帳的服務，它們的體驗和痛點都有被包含在考量裡。